As more programs and users have become accustomed to seeking access to applications, services and content sources (hereinafter resources) available over networks, it has become more common for providers of such resources to expose and serve up (hereinafter “expose”) their resources via a network. Conventionally, exposing resources requires employing a server program that consumes significant resources (e.g., processing cycles, disk, communication bandwidth). But some providers of resources may not require the comprehensive features provided by conventional servers and may not be able to afford the resources required by such “heavyweight” conventional servers. Thus, resources that could be made available over networks may not be made available, limiting the expansion and value of such networks.
Exposing resources over a network typically requires formatting communications in a protocol supported by the network. Such communication is typically handled by a server. For example, messages traversing the Internet can be formatted in protocols including, but not limited to, Hypertext Transfer Protocol (HTTP), File Transfer Protocol (FTP) and Simple Mail Transport Protocol (SMTP). Such a diversity of protocols facilitates communication between a wide range of devices, applications and/or processes in a variety of methods. But such diversity leads to problems for server programmers trying to expose resources through different networks and by different protocols to facilitate wide accessibility.
Conventionally, a server program written to expose resources provided over a network includes code specific to the protocol employed to transport messages across the network. For example, a programmer writing a peer-to-peer application for exposing files that can be shared across a network includes code specific to the protocol existing between the peer processes. By way of illustration, a file-sharing program may have to include HTTP specific code. Including such protocol specific code in a server program can negatively impact writing such a server program by requiring the programmer(s) involved in writing the server program to learn details of the protocol. Learning such details, and coding such protocol specific details can increase program complexity while reducing program flexibility.
Program flexibility can be important to programs exposing resources. For example, protocols change, and thus an inflexible program that cannot adapt to such changes will have restricted utility and shortened lifespan. By way of illustration, a program written to communicate specifically via HTTP 1.0 may not be able to communicate via HTTP 1.1. Thus, the server program may need to be rewritten and recompiled to take advantage of the newer protocol. By way of further illustration, peer-to-peer communications are characterized by dynamically formed ad hoc networks. Such dynamic ad hoc networks require servers capable of being protocol and URI agile. Server programs relying solely on protocol and URI specific code cannot provide the desired agility.
The dynamic ad hoc networks prevalent in peer-to-peer communications are typically established between peers with limited resources. For example, a college student with a personal computer may desire to establish a peer-to-peer network with his family and friends to share files. His family and friends may similarly only have available a set of small computers to engage in the desired communications. Conventionally, a server program written to expose resources provided over a network required large amounts of computer resources (e.g., processing cycles, disk space, network bandwidth) and thus the college student and his peers may not be able to establish the desired communications. Servers that require such large amounts of computer resources can be referred to as “heavyweight” servers. Heavyweight servers, therefore, can limit the ability to form ad hoc networks, and thus limit desired communications between peers.
Programmers writing server programs to expose resources addressable by a URI (Uniform Resource Identifier) typically are required to know the URI, to leave the resource at the known URI, to know the protocol employed to access the URI and to write code specific to the protocol required to access that URI. Thus, changing the URI of an application, service and/or content source could require a server program to be rewritten and recompiled, thus restricting the ability to move content from one location to another and introducing opportunities to introduce new bugs into a system when such relocation is attempted. Further, user written server programs conventionally are prevented from sharing a protocol (e.g., HTTP) namespace with a commercially provided server unless the user written server program can co-exist with (often by being dominated by) the commercial server. Further still, user written servers tend to consume the entire namespace on the machine on which they run, restricting a machine to running one server. But it can be advantageous to have a machine expose a plurality of smaller, less resource intensive resources (e.g., content source of a single page of data, a simple ZIP code lookup application, a simple file sharing service) through a plurality of small servers.
Programmers are further constrained by conventional systems and methods to transmit and receive messages in message sizes and formats dictated by a protocol. For example, a server exposing email content may be required to listen for requests for email where the requests are formatted as a packet with a header and trailer according to a first protocol. Similarly, a server exposing an encyclopedia may be required to listen for HTTP get requests consisting of a few words formatted according to a second protocol. Such protocol specific packaging and size restrictions add complexity to server programs and limit the ability of one server to expose multiple resources over a variety of protocols.
Thus a system and/or method for enabling server applications to expose resources and to communicate simply over a plurality of protocols is still needed to mitigate problems associated with conventional systems.